NOVA - For the NeXT Workstation/NOVA - For the NeXT Workstation.iso/Newsletters/GEnieUnixNews/unxnl-01.92

Text File | 1992-12-27 | 32KB | 712 lines

          _  _  _   _  _   _
         // // //| // // \//     N E W S
        //_// // |// //  /\\     Vol 3, Issue 1 - January 1992
      R o u n d T a b l e (tm)

   Items of interest to participants of the GEnie Unix RoundTable

       The RoundTable SysOps are:
       Andy Finkenstadt....ANDY       Rick Mobley.........LRARK
       Gary Smith..........GARS       Brian Riley.........DELPHI
                   All Unix SysOps.....UNIXSYSOPS$
   We strongly encourage you to contact any or all of us if you have -ANY-
 comments or suggestions. This is -YOUR- RoundTable. We are here to make
 your participation as pleasant and beneficial as possible.

 ######  HOT NEWS FLASH !  ######  HOT NEWS FLASH ! ######  HOT NEWS FLASH !

  GEnie Unix RoundTable has added guru level support for NeXT (Cat. 20),
  Sun (Cat. 19), Sequent (Cat. 21) and Mark Williams Coherent (Cat. 18).
  Watch for expanding coverage in the Support Categories in the Bulletin
  Board, more files in the library, and a detailed report next newsletter.

 ######  HOT NEWS FLASH !  ######  HOT NEWS FLASH ! ######  HOT NEWS FLASH !

 ED: editor notes - new start (GARS) Gary Smith
 --

   We have elected to change the format of the Unix RoundTable newsletter
 to bring it closer into compliance with what we perceive as our charter.
 Rather than a hodge-podge of articles, the newsletter will now be more
 in tune to the needs of those wanting to know more about Unix, whether they
 are starting from scratch or already come to the table with a array of
 skills.

   Beginning this issue we will be presenting series of tutorials aimed at
 increasing your understanding of Unix. Unix represents a toolkit of ready
 to use modules. Like a carpenter or mechanic the tools are worthless if you
 don't know how to use them. It is entirely possible to drive a screw into
 a board with a hammer, but the results are much more aesthetically pleasing
 if you use a screwdriver. The end product will function better, as well.

   This is also true of Unix. You have to gain a margin of skill equal to
 the tasks you wish to accomplish. Fellow SysOp, Rick Mobley, and I will
 be helping you with vi and shells in this issue. Andy and Brian will help
 develop your skills in other areas in a February issue. These are going to
 be serial tutorials, with each section taking the reader to a new level.

   There will still be short scripts, RoundTable news and humor pieces.
 The focus will just change to hands-on development. It must be noted here
 that you should try any exercises presented. Like riding a bicycle and
 dancing, computer usage is an acquired skill that can only be improved by
 doing.

   We invite your feedback. Do you approve or disapprove of the change in
 format? Tell us. We _really_ do want to know.

   We also invite your contributions. Please feel free... no, encouraged...
 to start your own series. I can think of at least a dozen of our regulars
 I would love to sit at the feet of, as each shared his/her knowledge.

 Library Handy Hint:  How to find general help files
 ------------------
 Use the browse feature with FAQ as your keyword. We have several help
 files that follow the 'Frequently Asked Questions' format, and will
 be adding more.

 FAST and NASTY, DOWN  and  DIRTY:  quick  fix scripts that do something
 --------------------------------

 [e-mail] on Usenet comp.unix.shell newsgroup offered
 this quick test.

 Subject: Dirtiest little sh test for program existence...

 I just discovered this little nice (:) method which kind of tests the
 existence of an executable within $PATH.  It goes like this:

 #!/bin/sh
 prog=$1
 if [ ! -z "$prog" ]; then
         case "`(. $prog 2>&1)`" in
             *"not found"*) echo $prog not found ;;
             *)             echo $prog found ;;
         esac
 fi

 So what do you people think?  Are there shell implementations that will
 puke on this one?

 --Harald E

 C-shell application note  How to put the current directory in the prompt
 ------------------------   (ANDY) Andrew Finkenstadt

 A recent question in the Unix Bulletin Board resulted in a quick
 search through my .cshrc, the C-Shell control file.  This file is
 executed each time /bin/csh is invoked, including as a subshell
 beneath an application program like 'vi' or 'mail'.  It is
 distinct from .login which is executed once each time you log in
 and run /bin/csh as your login shell.  (/bin/csh is the one that
 usually has the % prompt.)

 The question was "How do I get my prompt to reflect the current
 directory on my Unix computer?"   Well, on an MS-DOS or DR-DOS
 computer you would just set the prompt equal to the command that
 does this:

   C> SET PROMPT=$P$G
   C:\>

 This doesn't quite work under Unix.

 However, all is not lost.  The C-shell does allow for
 redefinition (or aliasing) of commands with the 'alias' command.
 The trick to making the prompt show the current directory is to
 redefine those commands which change the current directory into
 something that changes the prompt after doing the actual change.

 The following set of commands will redefine the 'cd', 'pushd',
 and 'popd' commands of the C-shell to set the prompt correctly.

        #!/bin/csh
        # ~/.cshrc
        # Copyright 1991, The GEnie Unix RoundTable.
        # All rights reserved.  Freely redistributable
        # so long as this copyright notice remains
        # intact.

        # set the variable mysystem = the name of the system
        # (useful in multi-machine network environs)
        set mysystem=`uname`

        # Equinox megaport has tty+aa for alternate terminal
        # we like a visual indication of this on the prompt
        if (`tty|cut -c9-9` == '+') then
           set vt=${mysystem}::
        else
           set vt=${mysystem}:
        endif

        # now redefine the actual commands to do
        # 1: the actual command
        # 2: reset the prompt to the right string
        # 3: read a file called .readme for those users who
        #    might get lost or developers who need reminders
        #    about what belongs in certain directories
        alias cd '\!#; reprompt; cat -s .readme'
        alias pushd '\!#; reprompt; cat -s .readme'
        alias popd '\!#; reprompt; cat -s .readme'

        # this line resets the prompt to what we want it to be
        # each time 'reprompt' is typed, which happens
        # automagically during the redefined cd command.
        alias reprompt 'set prompt="{${vt}${cwd}:!} "'

        # and make sure our first prompt is right, too.
        reprompt
        # end of ~/.cshrc

 Upload Contest Winner Announced   (ANDY) Andrew Finkenstadt
 -------------------------------   Unix RoundTable Lead SysOp

 The Unix RoundTable Sysops are pleased to announce the winner in
 our December 1991 Upload Contest.  A.ROSENBALM [J.] is our winner with
 timely uploads of some great NeXT workstation software.  He won
 both parts of our contest - the most number of files and the most
 number of bytes for the period in question - and will receive two
 free days of his choice in the Unix RoundTable as a result.

 It's not too late to win in January 1992 or future months either.
 For the complete rules, download the file CONTEST.RULES from the
 Unix RoundTable Library on page 160.

 Shell Programming (Script Style) (LRARK) Ricky Mobley
 -----------------

 This is the first of many articles that I will contribute to the newsletter
 in order to get some of you familiar with the power that awaits you at the
 command prompt. I have chosen 'sh' as my shell of choice since it is available
 on almost every Unix system and therefore considered the most common shell. I
 do not intend to start a 'shell war' discussion as everyone has their own
 favorite and they are all very usable. Simply put - learn this and the rest
 will make sense and become easier to grasp.

 This first submission will only deal with the basics. If you don't understand
 the basics, you will find yourself struggling later on. I do not claim to be
 an expert here, so any errors should be brought to my attention and I will
 give you credit for the find in a later issue.

 So, here we go!

 If we had to define the purpose of /bin/sh, it could best be summed up with
 the statement: "A command interpreter that can accept input from any input
 device, whether that be a file, keyboard or a port."

 Hopefully, if we can get input, we can process it or manipulate it using any
 one of a few hundred tools available in /bin or /usr/bin. You may even write
 your own script or 'C' program and really get creative.

 Sh is a command interpreter and a programming language. It is not a part of
 the operating system kernel, but an ordinary user program that reads commands
 entered at the keyboard and arranges for their execution.

 This may sound familiar to some that are moving from an MSDOS environment,
 I think you call them 'batch' files. But that is where the similarity ends.
 Now we can handle keyboard intervention, input from other files and even pass
 our results in and out of other commands or scripts.

 A simple command is a sequence of words separated by blanks or tabs. The first
 word in the sequence (numbered as 0), usually specifies the name of a command.
 Any remaining words, with a few exceptions, are passed to that command.

 Example:
 $ echo "Hello World!"

 Results:
 Hello World!
 $

 Remember writing that first program? Instant gratification! Results, and
 sometimes it was even predictable.

 The value of a simple command is its exit value if it ends normally or status
 if it ends abnormally.

 We can use this exit value or status to test for proper operation of our
 program and send the user messages if it fails. This is often included in
 scripts so the user has a way to quickly determine the proper syntax necessary
 to achieve the desired results of using such a program.

 For instance; I have a program called 'wipe' that I might use to completely
 erase a diskette. Since it is not a known fact as to where or which device
 might be used, I can choose to prompt you, or on a failure I can simply give
 you a syntax or a usage statement.

 Example:
 $ wipe

 Results:
 wipe - device name missing.
 Usage: wipe [device-name]
 $

 A command is either a simple command or a control command.

 A pipeline is a sequence of one or more commands separated by a | (vertical
 bar) or by a ^ (circumflex or caret). In a pipeline, the standard output of
 each command becomes the standard input of the next command. Each command
 runs as a separate process, and the shell waits for the last command to end.

 You will hear programmers refer to this as a 'pipe'. You can chain several
 commands together and achieve some dramatic results as long as you are
 careful.

 A filter is a command that reads its standard input, transforms it in some
 way, then writes it to its standard output. A pipeline normally consists of
 a series of filters. The exit value of a pipeline is the exit value of the
 last command.

 If a command fails along a pipeline using this technique the exit value may
 not indicate an error. Only the last command can pass the exit value back
 to the shell. The exception to this might be a core dump.

 A list is a sequence of one or more pipelines separated by ; (semicolon),
 & (ampersand), && (two ampersands), or || (two vertical bars) and optionally
 ended by a ; (semicolon) or an & (ampersand). These separators and
 terminators have the following effects:

  ;   Causes sequential execution of the preceding pipeline (the shell waits
      for the pipeline to finish).

  &   Causes asynchronous execution of the preceding pipeline (the shell does
      not wait for the pipeline to finish).

  &&  Causes the list following it to be executed only if the preceding
      pipeline returns a zero exit value.

  ||  Causes the list following it to be executed only if the preceding
      pipeline returns a nonzero exit value.

 So thats how we test it! Ok lets give it a try. So I have this list of items
 that I want to sort and remove duplicates and output to the screen. Lets get
 some tools. First we need a list of items, ok I'll grab a file off of the
 system called 'list_of_items' and hmmmm, I suppose I can just use 'cat' to
 display them. Now lets see, uhhhh, sort, sort, yea 'sort' thats it, and now
 what do I have to remove duplicates. Something that would only give me the
 items that were unique, lets see here..... 'uniq'. Ok, I think we are ready
 to go.

 $ cat list_of_items
 cat
 dog
 pig
 horse
 dog
 duck
 $

 $ cat list_of_items | sort | uniq
 cat
 dog
 duck
 horse
 pig
 $

 Presto! Sorry, no magic here just the desired results.

 The shell treats any word that begins with a # (number sign) as a comment and
 ignores that word and all characters following up to the next new-line
 character.

 So now our program takes shape and we can add comments by using the # to keep
 track of what we are trying to do.

 # A program to view a list of directories.
 # Ricky Mobley 30 Sep 1990
 echo Sub-directories of `pwd`          # Get the current directory to display.
 ls -l | grep "^d" || echo None found.  # Only display lines that begin with
                                        # drwx------.

 Here we 'echo' "Sub-directories of " using 'pwd' to get the 'print working
 directory'. Notice the grave-accent goes the other way to get this command
 to execute before we actually echo the results. Then we run 'ls -l' and pass
 the results through a pipe to 'grep "^d"' where we look for a "d" at the
 beginning of the line. If this fails, we didn't find any directories, then
 we echo "None found." and exit with a status of 0. Remember 'echo' was the
 last command in the pipe, so the program executed properly.

 Next time we will continue with the basics and keep expanding our knowledge
 to grow some more robust scripts. Who knows, we might just hit upon something
 that you can't live without.

 Ricky Mobley [lrark]
 Little Rock, AR

 vi - part 1, introduction  (GARS) Gary Smith
 ==   ------  ------------

   A tutorial on the Unix visual text editor from the GEnie Unix RoundTable

  -- abstract --

   This will be a multi-part tutorial on vi(), the Unix full screen editor
 most commonly encountered on all *nix platforms. Part 1 (this session)
 will provide an introduction to vi and provide a quick start overview so
 neophytes may use the power of vi() immediately, even if limited to basic
 edit functions.

   Subsequent articles will take the reader deeper into the mechanics of
 vi(), and should prove to be a valuable reference to even long time users
 of vi().

   Like many processes encountered in Unix, vi is one of those that becomes
 bottomless. The more you know about it, the more you will realize there is
 more to know. I can not hope to cover all possible contingencies one might
 encounter using vi. I will not even pretend it is possible. I do intend that
 this series will prove to be a valuable asset in any user's reference file.

  -- requirements --

   Using vi is not a spectator sport. If at all possible you should be sitting
 in front of a Unix worksation or terminal served by a Unix system and try the
 various operations as they are introduced to you. This can be your own Unix
 or Xenix system, a terminal at work or your own personal computer tied locally
 or via dial up lines to a Unix system. One of the beauties of vi is that it
 will function the same on all the above.

 -- setting up --

   The primary reason that vi is so universal as noted in the preceding
 paragraph is that it is curses oriented. That means that anyone using vi can
 thank Mark Horton for making their vi session function the same no matter
 what terminal they are using, though many terminals may use dramatically
 different sets of control codes to do things like clear the screen. Curses
 looks at your user profile (.profile or .login) to determine your terminal
 type then access the terminfo or termcap directories to fetch the appropriate
 code to do what you tell vi you wish to do next. vi itself addresses a virtual
 terminal with backspace, delete word and so on. It is curses and the terminal
 definitions that translate these virtual commands into terminal specific ones.

   The first thing that is necessary then before anyone can begin a vi edit
 session is insure the system knows what terminal you are using. To do this,
 simply type

      echo $TERM                            / carriage return will be assumed
                                              on all commands

   The system will respond with the terminal type it thinks you are using. If
 you are using a ms-dos computer logged into a public access Unix system the
 response should be

       ansi

   If terminal types are a total mystery to you ask your SysAdmin. He/she will
 be able to tell you if you are configured correctly. If you are on your own,
 try looking in /etc/termcap on BSD and /usr/lib/terminfo to determine your
 terminal type. These are quite different structured databases, but both are
 designed to provide the character-graphics information required by curses.

   If the system responds incorrectly and you know your terminal type, you can
 easily correct the problem by typing the following:

      TERM=terminal-type ; export TERM      / if you are using Bourne shell
                                              or Korn shell
      -or-
      setenv TERM terminal-type             / if you are using C shell

   It must be noted that this setting of the terminal type will only be valid
 for this login. To make the correction permanent the appropriate terminal
 type must be correctly defined in your user profile. Once you have learned how
 to use vi, you can do this yourself, provided you have permission to alter
 your user .profile or .login (C-shell only). If this is not your system have
 your SysAdmin make the change.

  -- general thoughts --

   Whether you realize it or not, the ability to edit files can safely be
 argued to be the single most important ability you should craft when using
 a computer. When you set up communication parameters you are editing a file.
 When you are establishing the correct switches in a make file you intend to
 compile on your system, you do so with an editor.

   Fellow GEnie Unix RoundTable SysOp, Rick Mobley (LRARK), makes the
 observation that if you are using ms-dos you should learn edlin, the line
 oriented editor available on ALL ms-dos systems. If you are using Unix you
 should learn to use ed(), the line oriented editor available on ALL Unix
 and Unix-like platforms. No matter what system you found yourself in front of,
 if you could perform the basic, line-oriented editing, you would at least have
 a start.  Rick makes a valid point.

   Most vi tutorials make this same assumption, and include learning ed() as
 part of learning vi. There is another reason for this in Unix. vi is a lineal
 descendant of ed and can perform all of the same functions as ed. I am NOT
 going to teach ed as part of this tutorial. I am going to make this strong
 admonishment. If you are not already familiar with ed, learn it now, and come
 back to vi properly equipped. This will be the only assumption I make. It is
 your responsibility to be prepared to learn vi by already knowing ed.

  -- a touch of history --

   As noted , ed() is the line oriented editor common to ALL Unix and Unix
 clones. ex() is a much more powerful editor co-implemented by Bill Joy and
 Chuck Haley that is actually a superset of ed(), and is seldom used by itself
 except on hardcopy terminals. vi() is the visual subset of ex and was the
 first Unix application to employ curses(). Later you may wish to prove some
 of this to yourself by calling a file to edit with ex() by typing

      ex filename

      then invoke vi from the ex colon prompt by typing

      :vi

      you will be instantly greeted with the vi screen

   If you would like to do this now, let's create a file called test. We will
 be playing with test throughout this tutorial, so now is as good a time as
 any to bring it up. If there is already a file named 'test' just name your
 practice file 'vitest'.

 -- getting started --

   There are many ways to invoke any editor, including a null file (no name),
 on a working file, or on an empty file as we are going to. Type

      vi test

      ... if you want to prove the ex/vi relation type

      ex test

      ex will respond

      "test" [New file]
      :

   At the colon type

       :vi

   Whether you invoked test with vi directly or with ex, then vi, the screen
 will be empty except for a single column of tildes (~) down the left side.
 A tilde only is vi's way of denoting an empty line.

      ~
      ~
      ~
      ~
      ~
      ~
      ~
      ~
      ~
      ~
      "test" [New file]

   This is also when you will probably discover if you have the right terminal
 defined. If you gave the system the incorrect terminal type then the editor
 may have just made a mess of your screen. This happens because it sends out
 control codes for one kind of terminal to an unrelated terminal. If you don't
 see a nice neat row of tildes on the left side of your screen and possibly a
 message to the effect "test" [New file] on the last line, don't panic. Type

      :q!

   Then notify your SysAdmin, or if you are on your own system try to figure
 the correct terminal type to tell Unix. If you are using a Lear Siegler ADM-3a
 or many CP/M systems like Kaypro-II try setting TERM=3a, a ms-dos machine will
 work with TERM=ansi, many DEC terminals will be TERM=vt100, vt52 or vt102.

   Some keys you will want to locate immediately are ESC (escape), CR (enter,
 return), DEL (rub) and the arrow keys. Your ESC may be labeled ALT. If you
 have an ESC and an ALT (ms-dos) they are NOT the same! ESC is the correct
 key you will come to love or hate very soon. If you don't have arrow keys, or
 the cursor does not respond to them (once there is text - the cursor can not
 move beyond the end of text in vi), don't panic. The h, j, k  and l keys will
 position the cursor. Many experienced vi users who must deal with a variety
 of terminal types prefer to use the letter keys as a matter of habit, thus
 maintaining an absolutely flat playing field. If you use a variety of
 terminals the more generic you can keep your commands the better.

  -- modes --

   The first thing you MUST learn is that vi is modal. This one aspect drives
 some users crazy. It also gives vi some of its advanced features and power.
 There two operating modes: 'text entry' and 'command' mode. (Some include
 last line operations as a third  mode). The _normal_ mode for vi is the
 command mode. Text entry mode is accessed from the command mode when you wish
 to type in, insert or replace existing text. To exit the text entry mode you
 press the ESCape key.

  -- inserting text --

   We are going to create some information in our test file so we will have
 something to practice edit commands on. Until you get familiar with some of
 vi's commands try not to hit the wrong keys, because almost every key can
 have some meaning to vi.

   There are several ways to enter text. The most common are

      - after the cursor
      - insert before the cursor
      - on the previous line
      - on the next line

   As you will soon discover one of the really nice things about vi commands
 is that nearly all commands are mnemonic.

   We are going to insert text. Type i (no carriage return) and type in the
 following text, including intentional errors (hit carriage return at the end
 of each line and carriage return alone on any null lines). Notice that the
 tilde will disappear and be replaced by text as characters occupy the line.

      This is a test file to be used for procticing various
      commands using the vi editer.

      As we insert more text we insert more text we also
      further complicat the file and add to possibilities
      for edit practice.

      Later we will expand beyond one screen to test various
      functions such as search and scrolling.
      ~
      ~
      ~
      ~
      "test" [New file]

   Notice that the status line has not changed. It continues to list the file
 name and fact that this is a new file. Once a status message is displayed it
 will remain until you scroll past the bottom (not yet possible) or until you
 execute a command that invokes a new status.

  -- cursor movement --

   Before you actually correct or add any text you need to know how to move
 the cursor. Before you can move the cursor with any key other than BACKSPACE
 you must exit text entry and return to the command mode. To do this hit the
 ESCAPE key. There will usually be an audible beep to accompany the change to
 command mode.

   If your terminal has cursor movement keys (arrow keys) and you wish to use
 them press one of them now to see if the cursor moves in the direction of the
 arrow. If you do not have cursor control keys, they do not work or you prefer
 to learn using the generic (letter) keys they are as follows:

      h - move the cursor left one character (so will backspace)
      j - move the cursor down one line
      k - move the cursor up one line
      l - move the cursor right one character (so will spacebar)

   Play with the cursor movement, insuring it does as expected and notice the
 following:

   If you attempt to cursor past the end of a line vi will beep. If you attempt
 to cursor left beyond the first character vi will beep. It will also beep if
 you attempt to move beyond the last line or above the first line.

   To move the cursor more than one position preceed the cursor key (letter or
 arrow) with the number of positions you wish to move.

      ie: 3j will jump the cursor down three lines.
          2k will jump the cursor up two lines

          try 5<spacebar> or 5<backspace>

       warning! spacebar and backspace do quite different things in command
       mode (cursor movement) and text entry mode (insert spaces or backspace
       over existing characters, deleting them in the process.

   vi also provides you with some handy one keystroke cursor jumps.

      0 (zero) - will jump to the beginning of the current line
      $ - will jump to the end of the current line
      G - will jump to the first character last line of the file

      There are others which we will investigate later.

   You will also discover vi is case sensitive. A lower case g does something
 quite different from the expected cursor jump. In this case vi will merely
 beep.

 -- adding text --

   If you can't cursor above the first line, below the last line and beyond
 text on the current line how do you add text to what is already there? We
 have six basic ways to learn for now, all of them mnemonic.

      i - (i)nsert text before the cursor
      I - (I)nsert text at the beginning of the current line
      a - (a)ppend text after the cursor
      A - (A)ppend text at the end of the current line
      o - (o)pen a line one line below the current line
      O - (O)pen a line one line above the current line

   Insure you are in the command mode by hitting ESC, type G to position your
 cursor at the beginning of the last line and type o (letter oh). This will
 open one line below. Add to our current test file the following line.

      This is one more line of text to mess with added with the o command.

   Your entire file should resemble the following:

      This is a test file to be used for procticing various
      commands using the vi editer.

      As we insert more text we insert more text we also
      further complicat the file and add to possibilities
      for edit practice.

      Later we will expand beyond one screen to test various
      functions such as search and scrolling.

      This is one more line of text to mess with added with the o command.
      ~
      ~
      ~
      ~
      "test" [New file]

 -- saving the file --

   This will conclude this session. To save your file for the next session
 make sure you are in the command mode by hitting ESC a couple of times and
 type:

      ZZ   (no carriage return)

   -or-

   type:

   : (colon) which will jump to the status line (this is actually returning you
 to the ex editor. Then type:

      :wq!  (carriage return)

   vi will save the file and post an exit status:

      ~
      ~
      "test" 11 lines, 373 characters

    __         _  Gary Smith           * ... uunet!ddi1!lrark!glsrk!gars  *
   / _' _   _ (_' P. O. Drawer 7680    *      [e-mail]     *
  /__/ (_|_/ '._) Little Rock,AR 72217 * GEnie Forth RT  &  Unix RT SysOp *
  ---------------        - U. S. A. -  * ph:501-227-7817,fax:[phone] *

 ---------------
   REMINDER - This newsletter is being sent to you 'by request'. If you do
 not wish to keep receiving it, e-mail a stop notice to GARS. On the other
 hand, we would very much appreciate it if you would pass the word that we
 do distribute this item near the tenth (10th) of the month of issue to any-
 one on GEnie who requests it, and will gladly add any name that is requested
 via the same route... e-mail to GARS.
   P L E A S E  also remember contributions are most welcome. Please e-mail
 items and/or suggestions to GARS.

 (EOF)

  Trademark and Copyright notices:
  Unix is a Trademark of UNIX System Laboratories, Inc.; GEnie, LiveWire, and
  RoundTable are Trademarks of General Electric Information Services  Company;
  Xenix and ms-dos are Trademarks of  Microsoft  Corporation;

 The contents of this newsletter are copyright (c) 1992 and may be copied whole
 or in part only if  original  credit is included. The GEnie UNIX RoundTable is
 not affiliated with AT&T or UNIX System Laboratories, Inc.